home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 153 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB

  1. From: thp@cs.ucr.edu (Tom Payne)
  2. Message-ID: <4ebrss$frt@galaxy.ucr.edu>
  3. X-Original-Date: 27 Jan 1996 00:33:32 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 27 Jan 96 00:52:24 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Throwing an exception from within a signal handler
  9. Organization: University of California, Riverside Department of Computer Science
  10. References: <4du0gr$8k8@galaxy.ucr.edu> <4e0moi$4dp@engnews1.Eng.Sun.COM> <4e35jg$k8c@galaxy.ucr.edu> <4e631s$2fg@hawk.hcsc.com>
  11. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMQl3UuEDnX0m9pzZAQH8QgF7B3/GzHvDFT0cgqWdCIYjCGp3JrsNqTeT
  14.     hLlQM9iwpOulcQn+s1Dt41qYpaZBQFB3
  15.     =hrns
  16.  
  17. Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
  18. : In article <4e35jg$k8c@galaxy.ucr.edu>, thp@cs.ucr.edu (Tom Payne) writes:
  19. : > If the ABI implementation of signal blocking is missing or has high
  20. : > overhead, then we can use global flags inside the program to reduce
  21. : > blocking to setting a bit and reduce unblocking to clearing that bit
  22. : > and checking whether a deferred signal has arrived (in which case
  23. : > there is additional overhead to check which signal to process it).
  24. : Maybe I've missed something here, but wouldn't that code have to appear in
  25. : every function prologue and epilogue?  The only reason for signal blocking
  26. : (I thought) was that trying to propagate an exception into or through a
  27. : stack frame that is partially constructed or destroyed is problematic.
  28. : I certainly wouldn't want code to check (and handle) a signal to be
  29. : generated in every function prologue!  Talk about code bloat!
  30.  
  31. We need to shrink-wrap critical sections where the stack might be in
  32. an inconsistent state (prologues and epilogues) against exceptions
  33. thrown by signal handlers.  We can do this by:
  34.  
  35.   1. setting a flag during such regions,
  36.  
  37.   2. having the compiler generate PC-range tables telling where 
  38.      these sections are,
  39.  
  40.   3. using some kind of pattern recognition to determine whether 
  41.      the interrupted function invocation was in a critical section.
  42.  
  43. Solution #1 involves at each critical section two writes and a
  44. conditional jump around a call to a function that throws deferred
  45. exceptions (as a proxy for the signal handler).  Solutions #2 and #3,
  46. proposed by David Chase, involve no overhead in time, but #2 involves
  47. some space overhead.
  48.  
  49. Steve Clamage has raised the question of existing libraries.  Under
  50. solutions #1 and #2, such libraries would have to be recompiled or
  51. else calls to them would have to be shrink-wrapped for the duration of
  52. the called function (leading to objectionable latencies if the
  53. shrink-wrapping blocks ALL signals).  Solution #3 would eliminate the
  54. need for recompilation, but you and Steve have expressed doubt about
  55. the feasibility of being able to programmatically detect these
  56. critical regions.
  57.  
  58.  
  59. Tom Payne (thp@cs.ucr.edu)
  60. ---
  61. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  62.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  63.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  64.